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I. 



INTRODUCTION 



The "Information Revolution" of the last few years has had 
tremendous impact upon all aspects of business and government. 

From its beginnings in the early 1950s with the introduction 
of the first general purpose electronic digital computers, the 
data processing environment has expanded and has become more 
and more complex, impacting upon more and more individuals with- 
in an organization, as well as the environment the organization 
operates in. The tremendous technological breakthroughs in com- 
puter hardware has led to increased availability and use of com- 
puters. New concepts had to be developed in order to more 
effectively understand and manage the data processing environment. 
Once management was able to recognize and describe this complex 
environment, it developed more sophisticated tools and techniques 
to deal with this environment. 

Information Resource Management (IRM) has become the watch- 
word of the eighties in regards to data processing. With the 
automation of the functions of an organization, data processing 
becomes vital to that organization. The information, and the 
data from which it is produced, become critical resources which 
any organization must manage efficiently and effectively. This 
management can be implemented through establishment of a data- 
base administration function highly placed in the organizational 
hierarchy. The database administrator is responsible for the 
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entire database environment of an organization, and must enforce 
effective and efficient administration of data resources and 
compliance vfith promulgated regulations by organizational per- 
sonnel. In an effort to control the entire database environment, 
the administrator should make use of available software tools, 
among them data dictionary systems and database management sysems. 

A data dictionary system provides effective centralized con- 
trol of data resources in a uniform manner across organizational 
boundaries. Data dictionary systems and database management 
systems complement one another in the management of the database 
environment. A data dictionary is vital in the effective collec- 
tion, specification and management of the total data resources 
of an organization. 

This thesis will explore the role of data dictionary systems 
in IRM. In order to better comprehend this role, key concepts 
of today's complex data processing environment will be discussed. 
Included in this discussion is the evolution of information sys- 
tems and database concepts from their earliest precursors, the 
importance of software life cycle management and the implemen- 
tation of IRM. A key component in effecting IRM is the data 
dictionary, which is covered in detail from its evolution to 
its present functions and future directions. Finally, the effect 
of legislative action upon the implementation of IRM and the 
use of data dictionaries by Federal agencies, particularly the 
United States Navy, will be explored. 
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II. CONCEPTS 



A. INFORMATION SYSTEMS 

The first general purpose electronic digital computer was 
introduced in 1951, inaugurating the "Computer Revolution" or 
"Information Revolution" of the twentieth century. Improvements 
in computer hardware and associated developments in software 
led to the introduction of subsequent generations of machines, 
the major characteristics of which are detailed if Fig. 1. Im- 
provements in hardware which produced faster, smaller, cheaper 
machines capable of processing and storing greater amounts of 
data have led to the explosive proliferation of computer usage 
into every facet of business and government. 

Early generations of machines were mainly focused upon hard- 
ware due to its cost. Software applications were initially a 
minor consideration. This focus has shifted over the years due 
to the dramatic decrease in the price of hardware and the equally 
dramatic increase in memory capacity, as can be seen in Fig. 2. 
Software became an important factor in effective and efficient 
utilization of the vast data processing and storage capacity 
of later generation machines. The change in the relative cost 
of software as opposed to hardware since the introduction of 
the first generation machines is shown in Fig. 3. 

Computer systems, composed of hardware and associated soft- 
ware, require data for processing. Without this data there is 
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Figure 1 — Characteristics of Computer Generations [Ref. 1] 
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TREND IN COMPUTATION SPEED 

(in multiplications per second — MPS) 

First generation 300 MPS 

Second generation 200,000 MPS 

Third generation 2 million MPS 

Fourth generation 20 million MPS 

TREND IN COMPUTATION COST 

Average cost of doing 100,000 multiplications 

1952 = $1.26 1958 = 26C 1964 = 12C 1974 = It 

Today the cost is a fraction of a cent 

TREND IN SPEED OF AN ELECTRONIC LOGIC CIRCUIT 

Mid 1950s (vacuum tube circuit) = 1 microsecond 

Early 1960s (transistorized printed circuit 

= 100 nanoseconds 

Late 1970s (integrated circuit chip) = 5 nanoseconds 

Mid 1980s (integrated circuit chip) = 1 nanosecond? 

TREND IN CIRCUIT COST 

Per integrated circuit chip 

1964 = $16 1972 = 75C 1977 = 15C 1985 = It ? 

Per bit of integrated circuit memory chip 

1973 = 0.5C 1977 = 0 . 1C 1985 = 0.005C ? 

TREND IN RELIABILITY OF ELECTRONIC LOGIC CIRCUIT 
Vacuum tube = one failure every few hours 
Transistor = 1000 times more reliable than vacuum tube 
Integrated circuit = 1000 times more reliable than 

transistor 



Figure 2 — Costs and Performances of Electronics [Ref. 2 ] 




Figure 3 — Hardware and Software Cost Trends [Ref. 3] 

13 



no reason for the system to exist. Additionally, personnel are 
required to operate the computer system which processes this 
data. Finally, these personnel should have prescribed proce- 
dures for effective and efficient operation of the system. 
Hardware, software, data, personnel and procedures are, there- 
fore, mandatory components of an Information System (Fig. 4). 



INFORMATION PROCESSING 




I — — 

Figure 4 — An Information System [Ref. 4] 

An Information System may be defined as: 

a system which uses personnel, operating procedures, and 
data processing subsystems to collect and process data 
and disseminate information in an organization. [Ref. 5] 

It is no longer possible to consider only the hardware facet 
in data processing. Sophistication has led to the need to con- 
sider every facet of an Information System and their interaction 
with each other. Of primary concern is the rising cost of per- 
sonnel and projected manning shortfalls in the next twenty years 
which increases the demand by an organization for the most effec 
tive and efficient management of an Information System. One 
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method for this improvement is increasing the number and/or 
use of software tools and implementing improved management pro- 
cedures /techniques . 

B . DATABASE 

Originally, computers processed programs composed of data 
and instructions to produce the information desired by an or- 
ganization. Due to limitations of memory capacity and the awk- 
wardness of coding in machine language, early applications were 
usually limited to automation of repetitive daily operations. 
Second and third generation machines, with their increased mem- 
ory capacity and more efficient data processing software inno- 
vations, allowed for more and more of an organization's operations 
to be computerized, but still remained relatively oriented toward 
automating the paperwork of an organization. Each application 
was developed independently, viewing its associated data in a 
proprietary fashion, creating and maintaining them as needed. 

The development of third and fourth generation machines gave 
the user increasingly extensive processing capabilities, but 
required a more comprehensive view by the user in order to fully 
realize their potential. In the very early days of computing, 
data and instructions were intermixed in the program. The most 
complex data structure applicable at this time was a "field" 

(or "string") consisting of meaningful groups of single alpha- 
numeric or other symbolic "characters" . More complex data struc- 
tures evolved--the "record" composed of related fields and the 
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file , itself a group of related records (Fig. 5) . 



File pro- 



cessing, which was utilized by second and third generation 




CHARACTER 



FIELD 

(NAME) 

composed of 

alphanumeric 

characters 

RECORD 
(EMPLOYEE) 
composed of 
NAME, SSN and 
SALARY fields 



FILE 

(PAYROLL) 
composed of 
individual 
EMPLOYEE 
records 



DATABASE 
(PERSONNEL) 
composed of 
logically 
related files 



Figure 5--Hierarchy of Data Elements 



machines, does not allow flexibility in data processing. Each 
application maintains its own files and reocrds separate from 
other applications, making data dependent upon the application 
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which utilized it. This leads to inconsistency and incompati- 
bility in the data, especially when data has been updated. An 
additional problem was the absence of an ability to combine data 
from separate files and records quickly and easily. New appli- 
cations had to develop data files from scratch, increasing the 
development cost. One-of-a-kind applications were usually not 
implemented due to the cost and time required to develop them. 

The database concept was developed in order to solve these pro- 
blems (Fig. 6 ) . 

A database is a nonredundant collection of logically rela- 
ted files. By definition, data redundancy prevalent with file 
processing is eliminated. Data is held collectively. More than 
one application may utilize the same data, allowing independence 
of data from applications. More sophisticated programming is 
possible, and new applications can be quickly and easily imple- 
mented. One-of-a-kind applications become economically feasible. 

While database processing solves many of the problems of 
file processing, there are some disadvantages attached to its 
use. Software programs are required for database management 
(i.e., Database Management Systems, or DBMS), which can be ex- 
pensive to purchase or develop. This additional software often 
requires increased hardware resources. The additional software 
interface increases the processing time, thereby increasing the 
cost of data processing. Database processing is complex, re- 
quiring more sophisticated programming and more highly qualified 
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operating personnel. Recovery and backup, in case of failure, 
is more difficult than with simpler file processing systems. 
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Finally, database processing has increased vulnerability to 
failure. However, even with these considerable drawbacks, the 
advantages of using database processing make it extremely de- 
sirable in today's data processing environment. 

In order to design a database, one requires conceptual rep- 
resentations of the real world. The most basic is the entity, 
which is the conceptual representation of an object. Kroenke- 
[Ref. 7] defines an object to be a phenomenon which can be rep- 
resented by a noun. During the design of the logical database, 
entities are unrestricted by the constraints of the computer. 
Entities will not be transformed into computer record format 
until the design of the physical database. Entities have attri- 
butes which characterize and describe them. In the real world, 
objects may be related to one another in associations. The con- 
ceptual representation of this is a relationship between entities. 
Relationships may also have attributes, as entities do. The 
conceptual representations pertaining to data must be defined 
during the design of the database. 

A database is a self-describing collection of integrated 
files [Ref. 8]. The self-describing aspect refers to the fact 
that the database contains a description of its own structure. 

The integration aspect refers to the fact that a database is 
not just a collection of files, but also contains the relation- 
ships which exist among these files. In order to process the 
database, one or more keys are necessary. The key is a field 
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which identifies a record. A key may be unique, identifying 
only one record, or nonunique, identifying a group of records. 
Database processing may also utilize record relationships. 

A database has three views of data: schema, subschema and 

physical. The schema, or conceptual view, is the complete, 
logical view of all the data in the database. From the control 
standpoint, however, it is inadvisable to allow every applica- 
tion access to the entire database. The subschema, or external 
view, defines a subset of the schema which is accessed by a spe- 
cific application. Since different applications may require 
the same data to some extent, subschemas may overlap. Subsche- 
mas may also reorganize the schema, depending upon the capabil- 
ities of the DBMS used. The third view, the internal, or physical 
view, describes how the data is physically arranged and how it 
is allocated to files. Each of these views must be defined be- 
fore database processing can occur. Usually, management person- 
nel define schemas and subschemas, while the DBMS defines the 
internal view when the database is defined. The variety of views 
of the same data which database processing offers allows sub- 
schemas to be tailored for the needs of the specific application. 
This means that each user sees the data in a familiar and useful 
format, even though the data is centralized and shared. 

C. SOFTWARE LIFE CYCLE 

Large, complex software systems require a large amount of 
effort and time to develop and are in use for an even longer 
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time. A number of distinct stages in the entire life span of 
the software can be identified. They are components of the 
software life cycle. These stages are: 

(1) . Specification 

The software requirements (i.e., the system functions 
and operational constraints) must be established and 
specified . 

(2) Design 

A software design must be derived from an analysis of 
the software requirements. 

(3) Implementation 

The software design must be converted into a program- 
ming language which can be executed on the target 
computer . 

(4) Testing 

The implementation must be tested to ensure that the 
completed system meets the software requirements. 

(5) Operation and Maintenance 

The system must be installed and used. If system er- 
rors are discovered, these must be corrected and 
changes to the original requirements may involve add- 
ing to the system. 

Software development, which encompasses the first four stages 
of the software life cycle, is an iterative process with feed- 
back from each stage to previous stages. During development, 
requirements may be clarified, implementation may reveal design 
flaws, testing may reveal errors in preceding stages and oper- 
ation may reveal errors which were undetected at earlier stages. 

In each instance, a change to correct a detected error will in- 
volve a recycling through the applicable stages of the life cycle. 

The operation and maintenance stage of the life cycle accounts 
for the major portion of the total software cost. Typically, 
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operation and maintenance costs are four times as much as the 
total cost of software development (stages one through four) , 
but can be as high as fifty times the cost of software devel- 
opment [Ref. 9]. Therefore, efforts aimed at reducing total 
life cycle costs are best concentrated on reducing the costs 
of the maintenance stage. As maintenance requires modifica- 
tion of the software, maintenance costs can be reduced by en- 
suring that the software is understandable and easy to change. 
This implies that specifications must be unambiguous, design 
and implementation tailored so that the software is composed 
of easy to modify modules and validation techniques are used 
to minimize the number of undetected errors. The earlier in 
the life cycle these errors are detected, the easier and less 
expensive they are to correct. 

In order to perform effective validation of the life cycle 
stages, requirements and design specifications must be unam- 
biguous. Unambiguous specifications are produced when formal 
notations are used and these specifications can be checked using 
software tools which have been developed for this purpose. Each 
stage should be thoroughly and properly documented, and where 
feasible, automatically checked for consistency and complete- 
ness. While this may increase the costs of software develop- 
ment, this increase is more than compensated for by a reduction 
in maintenance costs and, therefore, results in a reduction in 
the total software life cycle cost. 
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D. INFORMATION RESOURCE MANAGEMENT 



1 . Definition 



Due to the proliferation of computers, the increasing 
complexity and variety of applications and the scarcity of 
highly qualified personnel at ever escalating salaries, manage- 
ment became aware of the increasing need to manage Information 
Systems effectively and efficiently to the benefit of the or- 
ganization. The Information Resource Management (IRM) concept 
resulted from this recognition of management for the need to 
treat information as it would any other resource critical to 
the organization. The Workshop on Data Dictionary Systems and 
Information Resource Management (1980) defined IRM as: 

whatever policy, action or procedure concerning information 
(both automated and non-automated) which management estab- 
lishes that serve the overall current and future needs of 
the enterprise. Such policies, etc., would include consi- 
derations of availability, timeliness, accuracy, integrity, 
privacy, security, auditability, ownership, use and cost- 
effectiveness. [Ref. 10] 

Therefore, information policies, actions and procedures must 
be planned and executed organization-wide in order to truly 
treat information as a critical organizational resource. IRM 
is a reflection of the shift from systems designed around the 
processing methodology to systems designed around the data to 
be processed. 

2. Database Administrator 



The recognition of the IRM concept by managers leads 
to the recognition of the need for disciplined control of the 
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data of an organization. This control is incorporated in a set 
of management procedures and technical functions which comprise 
the emerging disciplines of database administration. 

Database administration encompasses all the technical 
and management activities required for organizing, maintaining 
and directing the database environment, which is considered to 
consist of the following: 

— the database (including automated and non-automated data) 

-- the database administrator (DBA) who manages the data- 
base environment 

— the software tools used in data administration and pro- 
cessing 

-- the users of the database 

The basic functions performed by the DBA include database defi- 
nition/redefinition, selection and procurement of hardware/soft- 
ware/services, database design/redesign, database creation, 
database security /integrity , database maintenance/management, 
database performance monitoring and evaluation, database enforce- 
ment, liaison with users/staff /management , and conversion of 
non-database systems to database systems [Ref. 11]. 

The DBA is responsible for planning, design, develop- 
ment, implementation, testing, documentation, operation and 
maintenance of the entire database environment. Due to the 
impact of database administration upon the entire organization, 
the DBA position should be placed high in the organizational 
hierarchy to ensure its success in enforcing effective and 
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efficient administration of data resources and compliance by 
members of the organization with database rules and regulations. 

3 . Software Tools 

a. Database Management Systems 

A DBMS is a software tool which provides an inte- 
grated source of data for multiple users, while presenting dif- 
ferent views of the data to different users. It can be 
characterized as generalized software which provides single flex- 
ible facility for accomodating different data files and opera- 
tions while demanding less programming effort than conventional 
programming languages. It features easy access to the data, 
facilities for storage and maintenance of large volumes of data, 
and, most importantly, the capability for sharing the data re- 
sources among different types of users. Since DDS are concerned 
with the management of data elements, it is logical that a strong 
relationship between DDS and DBMS exists. Some DDS interface 
with a variety of DBMS, while others require a specific DBMS 
in order to operate, while still others are embedded in an 
existing DBMS. 

DBMS evolved from the attempt to develop integrated 
application systems which were complicated by intricate data 
structures. The earliest DBMS was developed in the 1960s, 
based on hierarchic, network and inverted-tree data models. 
Continuing improvements in DBMS have caused these early models 
to be mostly superseded. Fig. 7 depicts the relationship of 
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the currently popular models. The database model is a vocab- 
ulary for describing the structure and processing of a database, 
and can be used for both logical and physical design of the data- 
base. It is also the basis for categorization of DBMS products. 
The database model is composed of Data Definition Language (DDL) , 
which is used to define the structure of the database, and Data 
Manipulation Language (DML) , which is used to describe the pro- 
cessing of the database. 
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Figure 7 — Relationship of Data Models [Ref. 12] 



While Fig. 7 depicts five data models, only three 
of these have actual DBMS products available. The Semantic 
Data Model (SDM) provides a means for expressing meaning as 
well as structure of database data. As such, it is the most 
logically and least physically oriented model, and lends itself 
particularly well to logical database design. The Entity- 
Relationship (E-R) Model is primarily a logical database model 
with some physical aspects. Though these models are convenient 
and lend themselves to the logical design of databases to describe 



26 



what the user wants to see, neither model has a DBMS implemen- 
tation at present and must be translated into physical data- 
base constructs once a particular DBMS product has been selected. 

The Conference on Data System Languages (CODASYL) 

Data Base Task Group (DBTG) Model is the oldest model listed 
in Fig. 7. A survivor of the earliest developments in data- 
base management, this model was developed in the late 1960s and 
is a physical database model, providing constructs defining 
physical characteristics of data, its location, data structures 
used for implementing record relationships and similar record 
relationships. Due to its physical nature, the CODASYL model 
is difficult to use for logical database design. Several DBMS 
products are available which are based upon this model, however, 
there are some detracting factors to its use. The model, na- 
turally, is geared towards COBOL, and is not easily implemented 
in organizations which utilize a language other than COBOL. 

Also, the model is very complex and somewhat incohesive. Some 
decisions regarding the model were based on group politics rather 
than technical merit. Finally, many variants on the core con- 
cept create confusion for the user. 

The Relational Model was first proposed by Dr. E. 

F. Codd in 1970, and has been the focus of a great deal of acti- 
vity, which has been largely theoretical in nature since com- 
mercial DBMS products based upon this model have only been 
available in the last few years. However, this model appears 
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to be the "new wave" in DBMS implementation. The significance 
of the Relational Model is that relationships are considered 
to be implied by data values. The principal advantage of car- 
rying relationships in the data is flexibility. Unlike the 
CODASYL Model, relationships need not be predefined in the de- 
sign of the database. 

DBMS-Specific Models are those DBMS which do not 
conform to any of the above models. These DBMS are based upon 
unique data models and some (e.g., ADABAS , TOTAL, IMAGE) have 
been commercially successful. Due to the variety among this 
category of DBMS, it is difficult to establish specific charac- 
teristics about them. Fig. 8 gives a brief summary of these 
models . 

The use of DBMS provides significant advantages in 
reducing the redundancy of stored data, avoiding inconsistencies 
in stored data, allowing for the sharing of stored data, main- 
taining data integrity and enforcing standards. However, the 
actual use of DBMS does not necessarily resolve all problems 
relating to the data administration function within an organi- 
zation, especially when the DBMS are used primarily for their 
storage and retrieval capability. This particular usage is not 
recommended, but frequently happens anyway. The increasing var- 
iety of DBMS products has resulted in instances within an organ- 
ization where more than one DBMS is employed within that 
organization, emphasizing the need for a facility which provides 
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uniform and centralized control of all the data resources of 
the organization. DDS is a tool which assists the DBA in per- 
forming this function. 
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Figure 8--Summary of Data Models [Ref. 13] 



b. Data Dictionary Systems 

With the growth of data resources of an organiza- 
tion, effective control cannot be maintained through the use 
of a DBMS alone. The DDS provides this vital central control 
function in a uniform manner across boundaries within an 
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organization. The DDS and DBMS complement one another in the 
management ot the database environment. Many of the benefits 
realized from the use of a DDS are parallel to those attributed 
to the use of a DBMS. However, there is a significant differ- 
ence in that the benefits realized from a DBMS are directly re- 
lated to the effective computer processing of the data, while 
the benefits realized from a DDS are directly related to the 
total data resources of an organization. Since the functions 
of a DDS coincide with the goals of database administration, 
it is one of the basic tools utilized by a DBA. 
c. Other Software Tools 

There are a great number of commercial software pro- 
ducts available which can assist the DBA in the management and 
control of the database. The two most important are DBMS and 
DDS. Other tools which are useful in database administration 
may exist as a separate, self-contained piece of software, as 
part of another piece of software or as a facility or utility 
of a DBMS, a DDS or an Operating System (0/S). Leong-Hong and 
Marron [Ref. 14] give the following list: 

Information/Data Retrieval System (IRS) — a program or set of 
programs which enables the user to retrieve information in a 
variety of formats; most modern IRS provide interface capa- 
bilities, including extensive user-oriented facilities and 
rapid response to system commands. 

Online Query System — a separate program or a DBMS feature 
which enables the user to interactively obtain information 
contained in a database. 

Data Entry System --provides facilities for automatic data 
entry and collection. Some provide interactive data entry 
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facilities, allowing for key verification, limited editing 
and formatting; others provide batch operation to enable 
massive data loading. 

Editor — facilitates selective modification and correction 
of data, program and document text. Special purpose edi- 
tors are available, geared towards entry, modification and 
editing of data, files, programs or texts. 

Flowchart Generator — produces a pictorial diagram of the 
flow of control and logical paths of a computer program; 
narrative documentation may also be produced. 

Text Processor — a documentation aid that accepts lines of 
source text interspersed with format control commands, and 
formats the text into a printable, paginated document with 
user-designed style. 

Report Generator — allows automatic generation of pre-for- 
matted reports on a production basis, or allows definition 
of ad-hoc reports, via parameters. 

Cross-Reference Genera tor - -pro duces listings of data ele- 
ments used in files, programs and systems indicating where 
data elements are being referenced. For programs, it pro- 
duces listings of the variables (data elements) used in 
programs, subroutines and systems, indicating where they 
are being referenced. 

Text/File Reformatter — rearranges and structures files 
according to specifications, and rearranges and struc- 
tures text and source programs for improved readability. 

Data/File Mainenance Programs — perform global changes for 
all, or selected, records in a file, while reporting changes 
in data context before and after operations. They may pro- 
vide data/file edit capabilities, and data items deleted 
or added may be flagged for audit trail purposes. They may 
be a separate software package, a utility program provided 
by an 0/S or a feature of a DDS or DBMS. 

Data Editing and Validation System --provides the user with 
the ability to perform data validity test, data editing, 
error correction and error reporting; or any subset of 
these tasks. 

Data Auditor — examines source data definitions and analyzes 
data relationships, data structures, formats and storage 
usages for consistency, validity and efficient utilization. 
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It may provide a dictionary or catalogue that contains 
definitions of the data attributes, and characteristics 
of the data type. It is available as a separate soft- 
ware package, but it is also a feature of a DDS or a DBMS. 

Data Security Module — may provide protection over sensi- 
tive data by encrypting/decrypting and by controlling ac- 
cess to the sensitive parts of the database. Security 
can be achieved through encoding/decoding or through ex- 
ecution-time password capabilites. 

Test Data Generator — produces test data files, according 
to specifications, which can be used for testing applica- 
tion software. 

Optimizers — apply changes directly to program source code 
in order to make them run more efficiently by reducing 
run-time or core requirements. They may perform analysis 
of the program for undetected errors and optimal logical 
flow. 

Automatic Space Generators — find available space for pro- 
grams or files that are awaiting processing. 

Scheduler — allocates available computing resources in order 
to optimize the use of resources to daily workloads. They 
may produce reports indicating the areas where optimization 
of the resources may occur. 

Project Manager — provides data collection, storage, and re- 
porting facilities aimed at personnel time and task account- 
ing. They may be coupled with other productivity and 
scheduling management aids. 

Librarian - -facilitates organized and economical storage of 
programs, texts, data sets, and object modules for central- 
ized retrieval and updates. They may collect accounting 
data to assist in storage allocation. 

E . SUMMARY 

The explosive proliferation of computers has led to the in- 
creasing importance of developing and implementing various man- 
agement concepts for effective and efficient operation and control. 
Emphasis has shifted from viewing a single component, computer 



32 



hardware, to consideration of the entire information system, 
composed of hardware, software, data, personnel and procedures. 
Increasing complexities in storage and retrieval of data has 
led to the development of the database concept. The critical 
role information has come to play in an organization's success 
has led to its recognition with the IRM concept. Finally, the 
increasing importance and visibility of the person or persons 
in charge of the organization's data has increased the interest 
in and need for effective and efficient management and control 
of data. One software tool which can provide this management 
and control is the DDS . 
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III. DATA DICTIONARY SYSTEMS 



A. EVOLUTION 

Data Dictionary Systems (DDS) are a relatively recent inno- 
vation in the field of data processing (DP) The earliest com- 
mercially available products were introduced in the early 1970 s, 
but these systems were relatively primitive and provided only 
a few functions. Impetus has gathered for improvement and ex- 
tension of DDS due to management acceptance of the IRM and 
Software Life Cycle Management concepts, as well as the ever 
increasing complexity of an organization's database. Control 
of the data resources is vital to the future success of an or- 
ganization, and this concern for control is evident in the in- 
creasing number of organizations implementing DBA functions 
within the organization and utilizing software tools for man- 
agement and control. 

Initially, the DP environment was relatively simple, re- 
quiring little in the way of management beyond coding programs 
and scheduling jobs to be run. Management of hardware resources 
was of primary concern to a relatively small DP department which 
was located several layers down in the organizational hierarchy. 
This was a reflection of the initial automating of daily repe- 
titive functions. With the growth and improvement of computer 
systems and evolution into a more complex information system 
concept, there was a concomitant demand for more effective and 
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management. As early, simple hardware management and 
scheduling techniques were automated through the use of more 
sophisticated software (i.e., 0/S), management could concern 
itself with more complex data management, integration and con- 
trol tasks. 

Extensive DP capacity led to the development of the data- 
base concept. Once management embraced this concept, it was 
necessary to develop techniques and software tools to manage 
it, resulting in DBMS being introduced in the early 1960s. 

With the growth in complexity and amount of data an organiza- 
tion required for operation, simple manual listings of the con- 
tents of data records, files and even databases was ineffective 
and outmoded. While DBMS was an effective tool for storing and 
retrieving data in a database and provided some control, it did 
not provide enough control to meet the objectives of IRM. DBMS 
reflects the emphasis prevalent in the late 1960s to early 1970s 
on data and data management. The emphasis has shifted in the 
1980s to information and IRM, which requires more than just data 
management in order to be effective. 

Since DBMS were developed before DDS , there is a natural 
tendency to view DDS as subordinate to DBMS, especially in in- 
stances where a DDS-like function is part of the DBMS or where 
DDS is dependent upon DBMS for operation. However, the increas- 
ing interest and improvements in DDS, and the development of 
DBMS-independent DDS, has caused it to evolve into a complex 
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software tool which should be considered equal to and allied 
with DBMS to effect IRM. 

The British Computer Society (BCS) established a study group, 
the Data Dictionary System Working Party (DDSWP) in January 1975. 
Over a period of time the BCSDDSWP worked to produce a report 
on the need for and the facilities which should be provided by 
a DDS and related database design and operational aids. They 
studied the then currently available DDS and related design aids, 
identified data recording and analysis needs for the design of 
information systems, specified requirements for aids to data- 
base design, maintenance and operation, and considered which 
of these requirements were automatable. The report of this 
study group was published in late 1977. This study emphasizes 
the shift which began in the mid 1970s to expanding the func- 
tions of a DDS from a software tool which was primarily involved 
with cataloging the data in an existing database into an adjunct 
to designing the database itself. Utilizing DDS in design of 
new software systems would assist in more effective management 
of the software life cycle and assist analysts and designers 
in determining undetected errors early in the software life 
cycle. It would also make maintenance of software easier and 
cheaper . 

B. DEFINITIONS 

Definitions of DDS range from Cardenas' (1979) relatively 
simplistic "centralized repository of data about data" [Ref. 15] 
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to the National Bureau of Standards' (NBS) (1982) definition 

of a DDS as a resource manager which is: 

an integrated repository that provides data necessary for 
managing data, where data management includes the planning, 
control, direction and organization of data. [Ref. 16] 

Other definitions include those of the BCSDDSWP (1977) : 

a tool for recording data and processing information about 
the structure and usage of data [Ref. 17]; 

Leong-Hong and Marron (1977) : 

a software tool that provides the means for defining and 
describing the characteristics of a database, as opposed 
to the contents of a database [Ref. 18]; 

and Allen, Loomis and Mannino (1982): 

an automated information system which achieves control of 
data by providing an inventory of data, control of costs 
of developing and maintaining applications by providing 
accurate and complete data definitions, and independence 
of metadata (i.e., data about data) across computing en- 
vironments, improving resiliency to hardware and software 
changes [Ref . 19] . 

The variety of definitions gives some idea of the evolving scope 
and increasing complexity of DDS. Originally envisioned as a 
database management tool, separate from and subsidiary to DBMS, 
DDS has evolved into being a primary componenet of a system for 
information management. In fact, it is proposed that DDS is 
an outdated concept and too restrictive for the IRM concept, 
which requires an Information Resource Dictionary System (IRDS) . 
An IRDS is: 

an information system with automated support which documents 
the information environment of an enterprise, supports the 
operational aspects of that information environment, illus- 
trates the interrelationships of information environment 
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components, and documents the locations of all components 
of the information environment. The Information Resource 
Dictionary (IRD) is the actual database manipulated by the 
IRDS software [Ref. 20]. 

Due to the increasing interest in the rapidly evolving na- 
ture of this field in recent years, terminology is somewhat con- 
fusing. One author speaks of a DDS while another refers to data 
element diet ionary /directory system (DED/DS) and, of course, 
the most recent developments are towards IRM and IRDS. NBS 
[Ref. 21] defines the following terms: 

Data Catalog: a listing of data elements 

Data Element Dictionary: describes each data element 

Data Element Directory: locates each data element 

Data Element Dictionary/Directory: describes and locates 

as well as lists each data element. 

Plagman [Ref. 22] further elucidates the difference between dic- 
tionary and directory functions by the type of user: dictionary 
users are human, while directory users are (usually) systems 
components (i.e., hardware / software ) . Since most commercially 
available packages have both dictionary and directory functions, 
apparently even those authors who speak of DDS are actually re- 
ferring to a DED/DS, which only adds to the confusion. In this 
thesis references to DDS will imply that a directory function 
is also available unless specifically stated otherwise. 
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C. FUNCTIONS 



In addition to the confusion generated by differences in 
terminology, the broad divergency of opinion as to the scope 
of a DDS further clouds the picture. The scope of a DDS can 
be quite narrow, covering only the database definitions neces- 
sary to support a DBMS, or exceedingly broad and grandiose, 
covering all data important to an organization, as with the IRM 
concept. The early DDS, and many installations' initial usage, 
centered around the directory functions, i.e., the DDS became 
the main database definition interface. This initial and basic 
function, the capture and documentation of data elements, their 
definitions, some of their descriptive attributes and some logi- 
cal grouping of these elements, has remained relatively constant 
over the years. 

In this aspect, a DDS must be able to identify data elements 
which are synonyms, homonyms or aliases. Synonyms are differ- 
ent names for the same data element which have become accepted 
due to common organizational usage. Homonyms are the same name 
having different meanings according to the context in which they 
are used. Aliases are different names for the same data ele- 
ment which are determined for DP technical reasons. These may 
be planned, as in the case of different programming languages, 
or unplanned, as in the case where no standards exist. In some 
situations, identifying occurrences of synonyms, homonyms and 
aliases and relating them to a single naming scheme is a large, 
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difficult and, occasionally, impossible task to carry out. It 
can be seen that it is not so much a situation of a DDS allow- 
ing an organization to standardize this aspect of DP as it is 
a necessity to have standards in order to facilitate optimal 
DDS function. However, a DDS permits more information to be 
recorded about elements, records, databases, etc., than what 
is available with just a database definition facility for a 
DBMS. The ability to document information about reports, users, 
programs, etc., has generated the impetus to develop DDS into 
a software documentation tool to support effective and effi- 
cient software life cycle management. 

Allen, et. al. [Ref. 23] delineates the components of a DDS 
as a database of metadata (i.e., data describing data, processes, 
users and processors of an organization) retrieval and analysis 
capabilities, management tools and functional interfaces. The 
metadata can be represented by a data model composed of entities, 
relationships and attributes, equivalent to the concepts used 
in DBMS. Various attributes which can be used for an entity, 
or a relationship, in a DDS include type, range, length, unit 
of measure, usage, language names, repetitions, keys, defaults 
and display formats. Relationships between entities of a typi- 
cal DDS are illustrated in Fig. 9. 

The typical functions performed by a commercially available 
DDS are displayed in Fig. 10. These functions are: 
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( 1 ) 



Database Maintenance: 

interprets and processes requests to add, change or 
delete contents of the database. 

(2) Extensibility: 

enables the database structure to be extended by the 
definition of additional entities, relationships and 
attributes . 

(3) Report Processor: 

provides predefined reports, the ability to customize 
reports and user defined reporting capability. Common 
predefined report types include: 

(a) name listings 

(b) relationship reports 

(c) detail reports 

(d) summary reports 

(e) matrix reports 

(f) graphical reports 

(4) Query Processor: 

allows English-like queries of the database (used for 
low volume retrievals). 

(5) Convert Functions 

reads application programs, libraries, and schemata 
and generates input transactions for the Database 
Maintenance Function (above) which describe the de- 
tected metadata. 

(6) Software Interface: 

provides a formatted pathway enabling DDS to provide 
metadata to other software systems and enables these 
systems to retrieve and update information in the 
database . 

(7) Exit Facility: 

enables the vendor-supplied routines to be extended 
(not available in all DDS) . 

(8) Database Management: 

performs database management tasks, e.g., security, 
integrity, concurrency control, and internal access 
for the database. This function is often performed 
by utilizing an existing DBMS, however, DBMS gener- 
ally does not provide all available subfunctions of 
this function. 
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Figure 9 — Logical Structure of a Typical DDS [Ref. 24] 
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Figure 10--DDS Functions [Ref. 25] 
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D. ROLE IN SOFTWARE LIFE CYCLE MANAGEMENT 

The software documentation • feature was not an aspect of the 
original DDS, which were more in the line of automated lists 
of data elements, but became the goal of developing DDS in the 
mid 1970s. The BCSDDSWP Report [Ref. 26], published in 1977, 
advocated the use of a DDS throughout the complete specifica- 
tion, design and implementation stages of the software life 
cycle. Particular functions which could be performed would be: 

(1) Data analysis, to determine the fundamental structure 
of the data of an organization 

(2) Functional analysis, to determine the way in which 
events and functions use data 

(3) Database or conventional file design 

(4) Storage structure design, where this is a further 
refinement of the initial database or file design 

(5) Operational running of the application systems 

(6) Collection and evaluation of performance statistics 

(7) Database tuning to improve performance 

(8) Application maintenance and database restructuring 

The BCSDDSWP Report further recommended that the DDS should 
provide two sets of facilities. One set would record and ana- 
lyze requirements independently of how they were to be met, the 
"conceptual data model". The second set would record design 
decisions in terms of the database or file structures implemen- 
ted and the programs that would access them, the "implementa- 
tion data structure". For both facilities it is necessary to 
record data usage as well as data structure, giving rise to four 
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areas of information which can be identified. Fig. 11 depicts 
these four areas. 
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Figure 11 — The Information in a Data Dictionary [Ref. 27] 



The DDS should relate definitions of the implementation data 
structure to the parts of the conceptual data model they describe 
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(i.e., records and items to entities). Recording this mapping 
documents the design decisions and clarifies the decisions which 
have been made. There should be a single conceptual data model 
for an organization, containing all new definitions in addition 
to the updated versions of old definitions. However, due to 
the evolution of data structures over time, there will be sever- 
al versions of each implementation data structure which opera- 
tionally must have clearly defined changeover times. 

In the specification stage of the software life cylce , use 
of a DDS will assist the analyst in recording the flow of data 
across functions. Additionally, conflicting usages can be iden- 
tified and resolved, and redundant data removed from the data- 
base or procedures implemented to ensure consistent update. 

The analyst can also use the DDS to predict the impact of a pro- 
posed change and define what actions should be taken to prevent 
unwanted side-effects. For the analyst the DDS is a device for 
collecting all the facts necessary for the clear and complete 
statement of the problem and for providing data to test the 
solution . 

In the design stage, the designer has the conceptual data 
model for a global view of the organization and where the new 
system fits within it. Verification and validation of speci- 
fications should be completed, as well as determining impacts 
upon present systems, if any. During this stage an implemen- 
tation data structure is constructed. The DDS provides 
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flexibility by allowing individual findings or decisions to be 
recorded in the appropriate places in the dictionary and pro- 
vide reference to any item of data of interest to the indivi- 
dual. The DDS not only provides a guide to the project under 
consideration, but also to the progress and to the documenta- 
tion. It is much easier to update a DDS than any manual system 
and, therefore, the DDS provides the most current and reliable 
form of cross-referencing system available for use in the soft- 
war life cycle. 

The implementation stage is more dependent upon hardware 
and supporting software than are the specification and design 
stages. If the conceptual data model and functional descrip- 
tion are developed in parallel, consistency is ensured. The 
implementation data structure and programs can then be designed 
with reference to conceptual/ functional model and implementa- 
tion constraints. The DDS may also be used as a programming 
aid by storing common source code, data to control software in- 
terfaces, data to control general maintenance and inquiry util- 
ities and statistics to be used as a basis for the creation and 
maintenance of test files. The DDS is also the source for DML 
generation as well as the schema and subschema generation for 
DBMS. 

E. ADVANTAGES OF USING DATA DICTIONARY SYSTEMS 

A DDS benefits many users in an organization. Allen, et. 
al. [Ref. 28] identifies the following user groups and the DDS 
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functions of their prime interest. 

(1) DBAs 

who use the system as a major tool for inventorying 
the data resource, implementing standards, and de- 
signing monitoring and restructuring databases. 

(2) Application Personnel 

(e.g., analysts and programmers) who use the system 
to reduce program coding efforts, store the designs 
of evolving systems and support analysis of system 
changes. 

(3) Operations Staff 

who retrieve information about jobs from the database. 

(4) DP Management 

who receive high-level impact and summary reports 
about data usage from the database. 

(5) End Users 

who obtain descriptions of their data views from the 
database . 

(6) Auditors 

who examine system documentation provided through the 
database . 

A DDS impacts upon the management of an organization by im- 
proving management's control and knowledge of the data resource. 
This control and knowledge is achieved by centralizing all in- 
formation about the data in a convenient tool--the DDS. Some 
of the advantages to using a DDS in an organization include the 
following aspects: 

(1) enables management to enforce data definition standards 

(2) eliminates unwanted data redundancy 

(3) aids in securing sensitive data 

(4) assists management in quickly determining impacts of 
proposed changes to a system 
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( 5 ) 



assists management in ensuring complete and accurate 
changeovers in the implementation of new systems 

(6) supplies information about the creation, usage and 
relationships of data 

(7) reduces the clerical load of a DBA 

(8) gives a DBA control over design and use of a data- 
base by: 

(a) controlling and documenting formulation, 
meaning and usage of data structures 

(b) evaluating and controlling data redundancy 

(c) providing accurage data definitions for 
programs 

(9) aids in the analysis of an organization's data flow 
by providing a method to track documents which flow 
through an organization 

(10) provides a central source of information for designers 
to prevent redundancy and inconsistency in system de- 
sign 

(11) generates test data for designers 

(12) provides documentation on systems design 

(13) enforces data definition standards during program 
coding 

(14) automatically generates code 

(15) improves accuracy of finished programs by generation 
of test data and checking results automatically 

(16) provides cross-referencing to assist in implementing 
approved changes to a system 

(17) automatically implements amendments to operational 
systems 

(18) provides documentation on changes to a system 

(19) aids operations personnel in the creation of job con- 
trol language parameters 

(20) determines the source of data (including invalid data) 
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The DDS will allow automation of documentation, program coding, 
test data creation and checking and auditing the system output. 
DDS, therefore, allows management and control of a critical or- 
ganizational resource — data. As this is the goal of IRM, it 
follows that use of a DDS will substantially assist an organi- 
zation in achieving effective and efficient IRM. 

F. SELECTION/EVALUATION CRITERIA 

When management decides to implement a DDS, the first con- 
sideration is whether to purchase commercially available soft- 
ware or develop one in-house. Due to the volatile nature of 
the field, it is highly probable that enhancements will improve 
and increase the effectiveness of the DDS. Additionally, de- 
signing a DDS for a specific implementation will require a great 
deal of effort, costing a large amount of money, especially if 
the system must be continually updated. Finally, the DDS used 
by an organization must be highly reliable. It is possible that 
undetected errors might be resident in an in-house developed 
DDS for longer periods of time than in a commercially availa- 
ble system. For these reasons, Lefkovits [Ref. 29] suggests 
that any DDS utilized by an organization should be a commercial- 
ly available system. 

Before initiating the selection process, an organization 
must determine if a DDS is justified based upon an economic 
analysis of costs and benefits or savings of implementing the 
system. As in any economic analysis, determining an actual 
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dollar value for savings or benefits may be extremely diffi- 
cult and is subjective judgement. Fig. 12 lists some aspects 
of costs and savings/benefits which should be considered in the 
economic analysis. Fig. 12 is not an all inclusive list; man- 
agement should determine actual cost/benefit categories to be 
considered applicable to their organization. 



COSTS 

Acquisition 
Data Administration 
Staff 

Hardware Costs 
Start-up Costs 
Data Collection Costs 
Maintenance 
Application System 
Changes 

User Education 



BENEFITS/ SAVINGS 

System Design and 
Development 
System Maintenance 
Data Redundancy 
Database Creation 
Auditing Information 
Resources 

Improved Communications 



Figure 12 — Costs and Savings/Benefits of DDS 



Selection of a DDS should be based upon who will use the 
system and how it will be used, rather than what is the most 
technologically innovative system available. Lefkovits [Ref. 
30] suggests the following selection and evaluation process: 

(1) Determine requirements; classify which requirements 
are mandatory and which are desirable features with 
an associated point scale indicating importance. 

(2) Develop a list of features to be used in the evalua- 
tion of DDS. 

(3) Determine a mapping from requirements to features; 
multiple mappings may be possible. 
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(4) Compare features, provided by commercially available 
• systems to each mapping to determine if a system 

qualifies for further consideration (i.e., possesses 
all mandatory features). 

(5) Compare those systems which qualify for the degree 
of compliance of any available desirable features, 
assigning a point value. 

(6) Sum point values assigned to desirable features of 
qualified systems to select the DDS which bests meets 
the requirements. 

This process is not without risk, especially since subjective 
judgement on the part of management is involved. The wrong 
system may still be selected for many reasons, including deter- 
mination of improper requirements, usually due to a lack of 
user involvement in the selection process; unnecessary features 
given high point values while mandatory features were given low 
point values, due to technical bias of selection team; incon- 
sistent evaluation of the system, due to different members of 
the selection team evaluating different systems as well as a 
lack of a well-defined measurement method; and undue emphasis 
on features needed in the future, but not at the time of imple- 
mentation, which could result in user dissatisfaction with an 
unnecessarily complex system. 

Once a system is selected and implemented, it should be 
evaluated periodically to determine whether or not it is per- 
forming acceptably. Often the requirements of the organization 
will change, requiring a reevaluation of the DDS to determine 
if it meets the new and/or changed requirements of the 
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organization. If the DDS no longer meets these requirements 
in an acceptable fashion, a new system must be selected. 

G. FUTURE DIRECTIONS 

No commercially available DDS is presently capable of pro- 
viding all functions envisioned for its use. This is not to 
say that the DDS currently available are worthless, just that 
there is room for a great deal of improvement. Curtice [Ref. 
31] notes that it appears that the use of DDS is proliferating 
without benefit of appropriate standards, adequate discipline 
or fundamental principles and methodology. Some of the contri- 
buting factors include: 

(1) lack of generally accepted standards, or even guide- 
lines, for what constitutes a good data definition 

(2) lack of clarity about which important characteristics 
of data should be recorded in a DDS 

(3) lack of a recognized and useful definition of "data 
element" 

(4) lack of accepted discipline of conceptual or logical 
database design 

(5) controversy about the best model for the conceptual 
level description of a database 

Areas where DDS are weak and require more development in 
future are a greater integration of DDS into actual software 
lift cycle management, more powerful query and analysis capa- 
bilities and redesign of user interfaces to make them more 
"user-friendly". However, the major topics for consideration 
in the future development of DDS are their use in distributed 
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networks, in mini- and microcomputer applications, and, above 
all, integration into IRM and evolution into an IRDS. 
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IV. DATA DICTIONARY SYSTEMS AND THE FEDERAL GOVERNMENT 



A. CONGRESS 

1 . Introduction 

Congress has enacted two key pieces of legislation 
which impact the implementation of DDS by agencies of the Fed- 
eral government. The Brooks Act has an indirect effect, being 
mainly concerned with the acquisition of automatic data pro- 
cessing equipment (ADPE) . The Paperwork Reduction Act of 1980 
on the other hand, establishes IRM as a mandatory government 
management concept. 

2 . The Brooks Act 

Public Law 89-306; 40 United States Code Section 
759 Section III to the Federal Property and Administrative Ser 
vices Act of 1949 is commonly known as "the Brooks Act" due to 
the sponsorship of Representative Jack Brooks (D-Tex) . It was 
enacted 30 October 1965 and authorized and directed the Admin- 
istrator of the General Services Administration (GSA) to 

coordinate and provide for the economic and efficient pur- 
chase, lease and maintenance of automatic data processing 
equipment by Federal agencies 

Prior to this time, Federal agencies pursued a course of pur- 
chasing or leasing ADPE based upon individual needs, resulting 
in large amounts of money being spent. Congress noted the in- 
creased government spending on ADPE and moved to control the 
proliferation of ADP systems within the Federal government. 
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The Brooks Act was the first attempt on the part of Congress 
to exert some type of control over Federal ADP spending. 

The Brooks Act tasks GSA with being the sole procurement 
agent for the Federal government for all ADP acquisitions, which 
authority may be delegated in situations deemed necessary to 
affect efficient implementation. GSA was also tasked with man- 
aging a pool of equipment which could be transferred among var- 
ious Federal agencies. The National Bureau of Standards (NES) 
was tasked with developing uniform Federal ADP standards to at- 
tempt to standardize Federal ADP operations. Finally, the Office 
of Management and Budget (OMB) was designated as policy maker 
and "referee" between GSA and user agencies in those cases of 
disagreement over the necessity of ADPE procurement. 

The Brooks Act, which was enacted prior to the emergence 
of software as a major portion of the cost of a computer system 
(see Fig. 3), specifically states its applicability to ADP hard- 
ware and hardware maintenance services. However, the increasing 
availability and cost of software and software maintenance ser- 
vices are making a notable impact upon acquisition of new or 
upgraded computer systems, causing some reevaluation of the 1965 
position. Commercially available software, which includes DDS, 
are now considered to be included in the provisions of the Brooks 
Act, and must, therefore, be purchased, leased or maintained 
efficiently and economically. 
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3 . 



The Paperwork Reduction Act of 1980 



Public Law 96-511; 44 United States Code Section 35, 
known as the Paperwork Reduction Act of 1980, was enacted 11 
December 1980 in order to reduce paperwork and enhance the 
economy and efficiency of the Government and the private sec- 
tor by improving Federal information policymaking. Represen- 
tative Jack Brooks, best known for his sponsorship of the Brooks 
Act, was also instrumental in the enactment of the Paperwork 
Reduction Act of 1980. The stated purpose of the act is: 

(1) to minimize the Federal paperwork burden for indivi- 
duals, small businesses. State and local governments, 
and other persons; 

(2) to minimize the cost to the Federal Government of 
collecting, maintaining, using and disseminating 
information; 

(3) to maximize the usefulness of information collected 
by the Federal Government; 

(4) to coordinate, integrate and, to the extent practi- 
cable and appropriate, make uniform Federal informa- 
tion policies and practices; 

(5) to ensure that automatic data processing and tele- 
communications technologies are acquired and used by 
the Federal Government in a manner which improves 
service delivery and program management, increases 
productivity, reduces waste and fraud, and, wherever 
practicable and appropriate, reduces the information 
processing burden for the Federal Government and for 
persons who provide information to the Federal Govern- 
ment; and 

(6) to ensure that the collection, maintenance, use and 
dissemination of information by the Federal Govern- 
ment is consistent with applicable laws, relating to 
confidentiality, including section 552a of title 5, 

United States Code, known as the Privacy Act. 
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The act further specifically defines data element and data 
element dictionary. A data element means a distinct piece of 
information such as a name, term, number, abbreviation or sym- 
bol, while a data element dictionary means a system containing 
standard and uniform definitions and cross references for com- 
monly used data elements. 

The Office of Information and Regulatory Affairs 
(OIRA) is a new office established by the Act within OMB. The 
Director of OIRA is responsible for developing and implementing 
Federal information policies, principles, standards and guide- 
lines, acting as a focal point for Federal information manage- 
ment policy. Included in the general information policy func- 
tions of the Director is the development and implementation of 
uniform and consistent IRM policies and the evaluation of Fed- 
eral agency information management practices to determine their 
adequacy and efficiency and to determine compliance of these 
practices with the policies, principles, standards and guide- 
lines promulgated by the Director. 

A stated goal of the Director of OIRA under the Act 
is to reduce the existing burden of Federal collection of in- 
formation by 15% by 1 October 1982, and to reduce the existing 
burden by an additional 10% by 1 October 1983. Additionally, 
the Director was tasked to establish the Federal Information 
Locator System, establish standards and requirements of agency 
audits of all major information systems, identify areas of 
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duplication in information collecting and develop a schedule 
and methods for reducing this duplication by 1 October 1981. 
Finally, the Director was to develop, in consultation with the 
Administrator of GSA, a five-year plan for meeting the ADP and 
telecommunications needs of the Federal Government by 1 October 
1982. 

Under the Paperwork Reduction Act of 1980 each Fed- 
eral agency is responsible for carrying out information manage- 
ment activities in an efficient, effective and economical man- 
ner and for complying with the information policies, principles, 
standards and guidelines prescribed by the Director of OIRA. 

Each Federal agency is required to designate a senior official 
or officials who report directly to the agency head to carry 
out the IRM responsibilities of the agency required by the Act. 

The Director of OIRA is tasked with the selective evaluation 
at least once every three years of the information management 
activities of each Federal agency to ascertain their adequacy 
and efficiency. 

A key part of the Act is the establishment of the 
Federal Information Locator System in the OIRA. The Act en- 
visions this system to be composed of a directory of informa- 
tion resources, a data element dictionary and an information 
referral service. The system is to serve as the authoritative 
register of all information collection requests (i.e., docu- 
ments calling for the collection of information ) or a centralized 
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listing of data available to Federal agencies. The system will 
promote data sharing and reduce data redundancy within the Fed- 
eral government. OMB is presently testing a system based upon 
the Information Requirements Control Automation System (IRCAS) 
of the Office of the Secretary of Defense (OSD) . IRCAS was de- 
signed to give OSD control over reports in an effort to elimi- 
nate duplication of information gathering. The system has been 
refined and updated and is presently being tested for possible 
implementation as the basis for the Federal Information Locator 
System. Testing will continue until at least March 1985. 

The Paperwork Reduction Act of 1980 is a direct re- 
sult of the recognition of Congress of the IRM concept and the 
necessity of implementing it to benefit the Federal Government. 
The key to IRM is to have the tools to manage information cheap- 
ly and effectively. The major tool to effect this management 
is DDS. 

B. NATIONAL BUREAU OF STANDARDS 

To utilize computer technology most effectively, it is de- 
sirable, to the extent feasible, to establish standards that 
are designed to achieve the maximum degree of compatibility and 
interchangeability among information systems. Federal agencies 
are required to implement and comply with the standards unless 
otherwise justified. This approach has far reaching and lasting 
benefits. From a management standpoint, the interchangeability 
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of equipment, programs and data throughout the entire Federal 
establishment would extend the efficiency and usefulness of 
Federal information systems, facilitate this orderly replace- 
ment as required and reduce the overall cost. 

One of the provisions of the Brooks Act was the tasking of 
the Secretary of Commerce with providing Federal agencies with 
scientific and technological advisory services relating to ADP 
and related systems, and to make appropriate recommendations 
to the President relating to the establishment of uniform Fed- 
eral ADP standards. The Brooks Act further authorized the Sec- 
retary to undertake any necessary research in the sciences and 
technologies of ADP computer and related systems required to 
support the duties assigned to the Secretary. OMB promulgated 
policy guidance to the Secretary of Commerce for the implemen- 
tation of the Brooks Act. This guidance identified five areas 
for specific actions: 

(1) Advisory and consulting services 

(2) Development of voluntary commercial standards 

(3) Recommendation for uniform Federal standards 

(4) Research on Computer Science and Techniques 

(5) Computer Services 

The Secretary exercises his technical and scientific advisory 
role through the NBS. NBS provides this support through the 
programs of the NBS Institute for Computer Sciences and Tech- 
nology (ICST) , which was established in 1966 in response to the 
new responsibilities assigned to NBS under the Brooks Act. 
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ICST's long range plan calls for the development of stan- 
dards and guidelines needed by Federal agencies to address the 
major problems of ADP use: to reduce the high costs 

to reduce the high costs of software development and main- 
tenance and to improve software quality; 

to encourage the more efficient use and interchange of data 

to better ADP operations, especially the security and inte- 
grity of operations; and 

to improve capabilities for interconnecting components, sys- 
tems and networks. 

These standards are promulgated, through GSA, as Federal Infor- 
mation Processing Standards (FIPS) and collectively constitute 
the FIPS Register. All Federal agencies should establish and 
maintain a FIPS PUB/FIPS Register in accordance with FIPS PUB 
0, "General Description of the Federal Information Processing 
Standards Register, 1 November 1968." Appendix A contains a 
listing of FIPS which have been published as of 31 March 1983 
(FIPSPUB99). Overall, FIPS aid Federal agencies in three pro- 
blem areas of computer compatibility (standard coding and data 
transfer), management and documentation, and security. FIPS 
are categorized as follows: 

General Standards 
Hardware Standards 

Character Recognition 
Interchange Codes and Media 
Transmission 
Interface 

Data Entry Equipment 

Computer Output Microfilm Readers 
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Software Standards 



Programming Languages 
Operating Systems 
Operating Procedures 
Media and Data Files 
Data Management Applications 
Software Engineering 

Federal General Data Standards 

Data Elements 
Representations and Codes 
Data Formats 

ADP Operations Standards 
Computer Security 

Benchmarking for Computer Selection 
Computer Performance Mangement 
Management of Multivendor ADP Systems 

In previous years ICST's technical assistance and research 
activities were limited to the direct support of standards de- 
velopment. However, recently ICST is beginning to research areas 
of increasing importance in Federal computer applications. Two 
major areas of interest are database technology and local area 
communications networking. In the area of database technology, 
ICST researchers are developing ways to express and manipulate 
the complex data structures involved in DBMS, DDS and other in- 
formation processing systems which are used by Federal agencies 
to manage and control their data resources and to provide the 
capability of data sharing among many users. 

The Federal Information Processing Standards Coordinating 
and Advisory Committee (FIPSCAC) coordinates the work assign- 
ments of a series of FIPS Task Groups which are established to 
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study specific topics relative to establishment of standards. 
Appendix B lists the various FIPS Task Groups. The draft pro- 
posals developed by FIPS Task Groups are reviewed by the FIPSCAC. 
The FIPSCAC also serves as a general advisory group to the Depart- 
ment of Commerce on information processing standards and advises 
on current and emerging issues relating to ADP standards. Each 
FIPS Task Group is composed of technical personnel with a know- 
ledge of their particular Federal agency's requirements. These 
personnel assist NBS in matters relating to the development, 
adoption and implementation of standards and in providing better 
coordination of the Federal ADP Standards Program. 

In May 1974, the Comptroller General of the United States, 
in a report to the Congress, noted that the cost for Federal 
data collection and data handling activities was estimated to 
exceed $5 billion annually [Red. 32]. There is, therefore, a 
great deal of pressure to reduce redundant data resources, and 
improve the utility of existing data resources. DDS is an 
appropriate tool for use by Federal agencies to eliminate un- 
necessary data gathering, reduce costs, and improve information 
systems' effectiveness. NBS established FIPS Task Group 17 in 
order to develop guidelines for constructing DDS and to identify 
relevant performance characteristics of the automated processes 
designed to use and maintain DDS. This Task Group produces two 
reports, NBS Special Publication 500-3, "Technical Profile of 
Seven Data Element Dictionary /Directory Systems," and NBS 



64 



Special Publication 500-16, "A Survey of Eleven Government- 
Developed Data Element Dictionary /Directory Systems," in 1977. 
Further research in this area by this Task Group resulted in 
the publication of FIPS PUB 76, "Guideline for Planning and 
Using a Data Dictionary System" of 20 August 1980. This guide- 
line provides assistance to Federal ADP Management and tech- 
nical staff in planning and using DDS , describing the capabilities 
of a DDS, discusses selection considerations, and provides gui- 
dance for preimplementation planning, implementation, and oper- 
ational use of a DDS. It is to serve as the basic reference 
document for general use by Federal agencies in the implementa- 
tion and use of a DDS. 

ICST is also engaged in a series of Database Directions 
Workshops in conjunction with the Association for Computing 
Machinery (ACM). The first workshop, held October 1975, was 
concerned with database fundamentals — language structures, 
standards needed to govern future growth and benefits to be ex- 
pected from the database environment. The second workshop, 
held 1-3 November 1977, addressed the conversion problem in- 
herent in adjusting from one database environment to another. 

The third workshop, held 20-22 October 1980, focused upon stra- 
tegies and tools for implementation of IRM. This workshop dealt 
primarily with DDS and their effective use as the major tool 
to implement IRM. Based upon the discussions of this third 
workshop, it would appear that the requirements of IRM go beyond 
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the capabilities of the currently available DDS. The evolution 
of DDS into IRDS for support of IRM, which is the current trend 
in the marketplace, was recognized by the workshop. It would 
appear that the next step would be research of the IRDS for pos- 
sible publication as a FIPS. 

C. DEPARTMENT OF THE NAVY 

The Department of the Navy (DON) , as an agency of the Fed- 
eral Government, is bound by legislative and executive policy. 
Therefore, whenever Congress enacts legislation affecting Fed- 
eral agencies, the Executive offices promulgate policy for those 
Federal agencies affected. 

The Brooks Act, having been in effect for over nineteen 
years, has given rise to a plethora of regulations governing 
Federal ADP management and procurement. Executive regulations 
which have been promulgated in response to the Brooks Act in- 
clude the Federal Property Management Regulations, the Federal 
Procurement Regulations and Federal Management Circular 74-5 
issued by GSA; eight OMB Circulars (including Circular A-71 and 
A-75) ; various reports and studies published by the General Ad- 
ministration Office (GAO); and the FIPS published by NBS . 

GSA is the major agency affecting ADP acquisition procedures, 
with additional guidance provided by OMB and NBS. This guidance 
provides the framework within which the Department of Defense 
(DOD) and DON must operate. Within DOD there are a multitude 
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of regulations governing ADP management and procurement, chief 
among them DOD Directive 4105.00, "Selection and Acquisition 
of Automatic Data Processing Resources," and DOD Instruction 
5100.40, "Responsibility for the Administration of the DOD Auto- 
matic Data Processing Program." DON, in turn, has implemented 
regulations promulgating this policy within the Navy. The 
Secretary of the Navy (SECNAV) has over forty instructions in 
effect, the most important of which is SECNAV Instruction 5236. 1A, 
"Specification, Selection, and Acquisition of Automatic Data 
Processing Equipment." At the next lower level in the hierarchy, 
the Chief of Naval Operations (CNO) or OPNAV level, there are 
over 35 instructions containing information regarding ADP man- 
agement specifically applied to the Navy. 

As can be seen by the vast numbers of regulations implemen- 
ted at each level of the hierarchy from Congress to DON, ADP 
acquisition and management is viewed very seriously by the Fed- 
eral Government. This desire for effective and efficient man- 
agement and control of ADP resources and the recognition of the 
newly emerging concept of IRM by the Federal Government has led 
to further legislation in the form of the Paperwork Reduction 
Act of 1980. As with any Congressional enactment covering a 
broad topic involving many hierachical levels in the Federal 
Government, there is some lag between Congressional action and 
Federal agency implementation. 
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CNO directed the establishment of the Information Manage- 
ment Division (OP-945) as of 1 August 1983 [Ref. 33]. He also 
effected an organizational realignment of functions and resources 
of the Navy Records and Information Management Division (OP-09B1), 
which was disestablished 15 January 1984 [Ref. 34]. The pur- 
pose of the realignment was to provide for increased attention 
by the Navy to information systems management, including a shift 
of emphasis from ADP hardware and software to IRM. Under the 
direction of OP-094, Command and Control, OP-945 is responsible 
for the development of program policy. Commander, Naval Data 
Automation Command (COMNAVDAC) is responsible for program exe- 
cution, as assigned by CNO, upon development of a strategic im- 
plementation plan by OP-945. COMNAVDAC is to submit an update 
to OPNAVINST 5450,200, "Mission and Functions of COMNAVDAC,” 
reflecting the establishment of OP-945 for CNO review by 1 March 
1984. The contents of OPNAVNOTE 5430 of 11 January 1984 will 
be incorporated into the OPNAV Organization Manual in the near 
future . 

CNO also directed the revisions of OP-945 mission and func- 
tions. The revised mission is: 

To ensure optimum Navy information systems — ashore and 
afloat, combat and support--by providing policy, guidance, 
planning, standards, and assessment and to serve as Direc- 
tor, Department of the Navy Information Resources Manage- 
ment in direct support of the senior official designated 
in accordance with the Paperwork Reduction Act of 1980 
(PL 96-511) [Ref. 35] . 
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In support of this mission, 24 functions are identified for 
performance by OP-945 (Appendix C) . 

The actual strategic implementation of the mission and func- 
tions of OP-945 is in the process of being drafted. Upon CNO 
approval of OP-945 strategic plan to establish a Navy-wide IRM 
policy, COMNAVDAC will be responsible for execution. It appears 
most probable that a DDS will be part of the strategic plan, 
in direct support of the function to register and standardize 
data elements. DDS could also support the effective and effi- 
cient use of information systems technology in support of DON 
missions, validation of information requirements, and develop- 
ment of information methods and techniques. 

It can be seen that with the passage of the Paperwork Re- 
duction Act of 1980 and the establishment of OP-945 that the 
Federal Government and the Navy have fully accepted and en- 
dorsed IRM. Implementation of IRM is vital to ensuring suc- 
cessful and integrated DP operations. As a key to the success 
of IRM within an organization, DDS will also play a vital role 
in the future of DP within the Navy. 
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V. CONCLUSIONS 



The advances made in DP since the introduction of the first 
general purpose computers in 1951 have led to an explosive pro- 
liferation of computer usage in the last ten years. As more 
and more operations vital to an organization become automated, 
the actual processing of data and the information which is pro- 
duced from it become critical to the operation of that organi- 
zation. In order to effectively and efficiently manage and 
control information, as it would any other critical organiza- 
tional resource, management must implement and support IRM. 

One tool which management can utilize to effect IRM is the DDS . 

DDS are presently in an evolutionary state. DDS implemen- 
tation has lagged somewhat behind that of the earlier developed 
DBMS, and the confusion regarding scope, definition and integra- 
tion of currently available DDS somewhat hinders the effective 
and widespread implementation of DDS. Many functions which DDS 
purport to possess are largely theoretical in nature. System 
complexities and lack of user education often lead to erroneous 
or misdirected use of DDS, in those instances where they are 
present. However, increasing interest and attention in this 
area has led to improvements in DDS as well as their potential 
for development into even more complex IRDS. The IRDS, present- 
ly at the theoretical stage, would effect even greater support 
of IRM within an organization. 
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IRM is a relatively recent innovation which is presently 
revolutionizing the DP environment. Recognition of IRM as an 
essential component of the successful management of an organ- 
ization has even reached agencies of the Federal Government. 
Without IRM, no organization will be able to effectively func- 
tion in the future DP environment. Without DDS, no organization 
will be able to effectively implement IRM. 
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APPENDIX A 



LISTING OF FEDERAL INFORMATION PROCESSING STANDARDS (FIPS) 



I . GENERAL 

General Description of the Federal Information Processing Stan- 
dards Register 
FIPSPUBO 1 November 1968 

Federal Information Processing Standards Index 
FIPSPUB1 2-2 1 December 1974 

Objectives and Requirements of the Federal Information Pro- 
cessing Standards Program 
FIPSPUB23 15 February 1973 

Standardization of Data Elements and Representations 
FIPSPUB28 5 December 1973 

Interpretation Procedures for Federal Standard COBOL 
FIPSPUB29 30 June 1974 

Guide for the Use of International System of Units (SI) in 
Federal Information Processing Standards Publications 
FIPSPUB34 1 January 1975 

Guide for the Implementation of Federal Information Pro- 
cessing Standards (FIPS) in the Acquisition and Design of 
Computer Products and Services 
FIPSPUB80 19 December 1980 



72 



II. HARDWARE STANDARDS 



A. Character Recognition 

Optimal Character Recognition Character Sets 
FIPSPUB32-1 25 June'l982 

Character Set for Handprinting 
FIPSPUB3 3 1 October 1974 

Guideline for ODtical Character Recognition Forms 
FIPSPUB40 1 May 1976 

Optical Character Recognition (OCR) Inks 
FIPSPUB8 5 7 November 1980 

Optical Character Recognition (OCR) Character Positioning 
FIPSPUB8 9 4 September 1981 



B. Interchange Codes and Media 

Code for Information Interchange 
FIPSPUB1-1 24 December 1980 

Perforated Tape Code for Information Interchange 
FIPSPUB2 1 November 1968 

Recorded Magnetic Tape for Information Interchange 
(800 CPI, NRZ I ) 

FIPSPUB3-1 1 November 1968 

Implementation of the Code for Information Interchange and 
Related Media Standards 
FIPSPUB7 7 March 1969 

Rectangular Holes in 12-Row Punched Cards 
FIPSPUBl 3 1 October 1971 

Hollerith Punched Card Code 
FIPSPUB14-1 24 December 1980 

Subsets of the Standard Code for Information Interchange 
FIPSPUBl 5 1 October 1971 

Recorded Magnetic Tape for Information Interchange (1600 
CPI, Phase Encoded) 

FIPSPUB2 5 30 June 1973 
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One-Inch Perforated Paper Tape for Information Interchange 
FIPSPUB2 6 30 June 1973 

Take-Up Reels for One-Inch Perforated Tape for Information 
Interchange 

FIPSPUB2 7 30 June 1973 

Code Extension Techniques in 7 or 8 Bits 

FIPSPUB35 1 June 1975 

Graphic Representation of the Control Characters of ASCII 
(FIPSPUBl ) 

FIPSPUB36 1 June 1975 

Recorded Magnetic Tape for Information Interchange, 6250 
CPI (246 CPMM) , Group Coded Recording 
FIPSPUB50 1 February 1978 

Magnetic Tape Cassettes for Information Interchange (3.810 
MM [0.150 IN] Tape at 32 BPMM [800 BPI] , Phase Encoded) 
FIPSPUB51 1 February 1978 

Recorded Magnetic Tape Cartridge for Information Interchange 
4-Track, 6.30 MM (h IN), 63 BPMM (1600 BPI), Phase Encoded 
FIPSPUB52 15 July 1978 

Computer Output Microform (COM) Formats and Reduction Rations, 
16 MM and 105 MM 
FIPSPUB54 15 July 1978 

Guideline for Inspection and Quality Control for Alphanumeric 
Computer-Output Microforms 
FIPSPUB82 26 September 1980 

Magnetic Tape Cassettes for Information Interchange, Dual 
Track Complementary Return-to-Bias (CRB) Four-States Re- 
cording on 3.81 MM (0.150 IN) Tape 

FIPSPUB9 1 12 March 1982 

Parallel Recorded Magnetic Tape Cartridge for Information 
Interchange, 4-Track, 6.30 MM ( h IN), 63 BPMM (1600 BPI), 

Phase Encoded 

FIPSPUB9 3 29 June 1982 
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C. Transmission 

Bit Sequencing of the Code for Information Interchange in 
Serial-by-Bit Data Transmission 
FIPSPUB16-1 1 September 1977 

Character Structure and Character Parity Sense for Serial- 
by-Bit Data Communication in the Doce for Information In- 
terchange 

FIPSPUB17-1 1 September 1977 

Character Structure and Character Parity Sense for Parallel- 
by-Bit Data Communication in the Code for Information Inter- 
change 

FIPSPUB18-1 1 September 1977 

Synchronous Signaling Rates Between Data Terminal and Data 
Communication Equipment 
FIPSPUB22-1 1 September 1977 

Synchronous High Speed Data Signaling Rates Between Data Ter- 
minal Equipment and Data Communications Equipment 

FIPSPUB37 15 June 1975 

Advanced Data Communication Control Procedures (ADCCP) 

FIPSPUB7 1 14 May 1980 

Guideline for Implementing Advanced Data Communication Control 
Procedures (ADCCP) 

FIPSPUB78 26 September 1980 



D. Interface 

I/O Channel Interface 
FIPSPUB60-1 27 August 1979 

Channel Level Power Control Interface 
FIPSPUB61-1 13 July 1982 

Operational Specifications for Magnetic Tape Subsystems 
FIPSPUB62 16 February 1979 

Operational Specifications for Rotating Mass Storage Subsystems 
FIPSPUB63-1 14 April 1983 

Operational Specifications for Fixed Block Rotating Mass Stor- 
age Subsystems 

FIPSPUB97 4 February 1983 
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E . Data Entry Equipment 

Guideline for Selection of Data Entry Equipment 
FIPSPUB67 . 30 September 1979 

F. Computer Output Microfilm Readers 

Microfilm Readers 
FIPSPUB84 31 October 1980 
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III. SOFTWARE STANDARDS 



A. Proqramming Language 
COBOL 

FIPSPUB21-1 1 December 1975 

Interpretation Procedures for Federal Standard COBOL 
FIPSPUB29 30 June 1974 

Aid for COBOL Program Conversion (FIPSPUB2 1 to FIPSPUB21-1 ) 
FIPSPUB43 1 December 1975 

Federal Standard COBOL Pocket Guide 
FIPSPUB4 7 1 February 1977 

Minimal BASIC 

FIPSPUB6 8 4 September 1980 

FORTRAN 

FIPSPUB69 4 September 1980 



B. Operating Systems 



C. Operating Procedures 

Magnetic Tape Labels and File Structure for Information Inter- 
change 

FIPSPUB79 17 October 1980 



D. Documentaion 

Dictionary for Information Processing 
FIPSPUBll-1 30 September 1977 

Guidelines for Describing Information Interchange Formats 
FIPSPUB20 1 March 1972 

Flowchart Symbols and Their Usage in Information Processing 
FIPSPUB24 30 June 1973 

Software Summary for Describing Computer Programs and Data 
Systems 

FIPSPUB30 30 June 1974 
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Guidelines for Documentation of Computer Programs and Auto- 
mated Data Systems 
FIPSPUB38 15 February 1976 

COBOL Coding Form 
FIPSPUB44 1 September 1976 

Transmittal Form for Describing Computer Magnetic Tape File 
Properties 

FIPSPUB53 . 1 April 1978 

Guidelines for Documentation of Computer Programs and Auto- 
mated Data Systems for the Initiation Phase 
FIPSPUB64 1 August 1979 



E. Media and Data Files 

Code for Information Interchange 
FIPSPUB1-1 24 December 1980 

Message Format for Computer-Based Message Systems 
FIPSPUB98 1 March 1983 



F. Data Management Applications 

Guideline for Plannina and Using a Data Dictionary System 
FIPSPUB7 6 20 August 1980 

Guideline for Planning and Management of Database Applications 
FIPSPUB77 1 September 1980 

Guideline on Integrity Assurance and Control in Database Admin- 

istration 

FIPSPUB88 14 August 1981 



G. Software Engineering 

Guideline: A Framework for the Evaluation and Comparison of 

Software Development Tools 
FIPSPUB99 31 March 1983 
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IV. FEDERAL GENERAL DATA STANDARDS 



A. Data Elements 



B. Representations and Codes 
Calendar Date 

FIPSPUB4 1 November 1968 

States and Outlying Areas of the United States 
FIPSPUB5- 1 15 June 1970 

Countries and County Equivalents of the States of the United 
States 

FIPSPUB6-3 15 December 1979 

Standard Metropolitan Statistical Areas (SMSA) 

FIPSPUB8-4 30 June 1974 

Congressional Districts of the United States 

FIPSPUB9 14 November 1969 

Countries, Dependencies, and Areas of Special Sovereignty 
FIPSPUB10-2 ‘ 15 November 1976 

Guidelines for Registering Data Codes 
FIPSPUB19 1 February 1972 

Guide for the Development, Implementation, and Maintenance of 
Standards for the Representation of Computer Processed Data 
Elements 

FIPSPUB45 30 September 1976 

Guideline for Codes for Named Populated Places and Related En- 
tities of the States of the United States 
FIPSPUB55 5 February 1982 

Representations of Local Time of the Day for Information In- 
terchange 

FIPSPUB58 1 February 1979 

Representations of Universal Time, Local Time Differentials, 
and United States Time Zone References for Information Inter- 
change 

FIPSPUB59 1 February 1979 
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Standard Industrial Classification (SIC) Codes 
FIPSPUB66 15 August 1979 

Representation of Geographic Point Locations for Information 
Interchange 

FIPSPUB70 24 October 1980 

Guideline for Standard Occupational Classification (SOC) Codes 
FIPSPUB92 24 February 1983 

Codes for the Identification of Federal and Federally-Assisted 
Organizations 

FIPSPUB9 5 23 December 1982 



C. 



Data Formats 



V. ADP OPERATIONS STANDARDS 



A. Computer Security 

Guidelines for Automatic Data Processing Physical Security and 
Risk Management 
FIPSPUB3 1 June 1974 

Glossary for Computer Systems Security 
FIPSPUB39 15 February 1976 

Computer Security Guidelines for Implementing the Privacy Act 
of 1974 

FIPSPUB4 1 30 May 1975 

Data Encryption Standard 
FIPSPUB46 15 January 1977 

Guidelines on Evaluation of Techniques for Automated Personal 

Identification 

FIPSPUB4 8 1 April 1977 

Guidelines for Automatic Data Processing Risk Analysis 
FIPSPUB6 5 1 August 1979 

Guidelines for Security of Computer Applications 
FIPSPUB7 3 30 June 1980 

Guideline on User Authentication Techniques for Computer Net- 
work Access Control 
FIPSPUB8 3 29 September 1980 



B. Benchmarking for Computer Selection 

Guidelines for Benchmarking ADP Systems in the Competitive Pro- 
curement Environment 
FIPSPUB42-1 15 May 1977 



Guideline on 
FIPSPUB75 



C. Computer 

Guideline on 
FIPSPUB49 



Constructing Benchmarks for ADP System Acquisitions 
18 September 1980 



Performance Management 

Computer Performance Management: An Introduction 
1 May 1977 



81 



Guidelines for the Measurement of Interactive Computer Ser- 
vice Response Time and Turnaround Time 
FIPSPUB57 1 August 1978 

Guidelines for the Measurement of Remote Batch Computer Service 

FIPSPUB72 1 May 1980 

Guideline for Developing and Implementing a Charging System 
for Data Processing Services 
FIPSPUB96 6 December 1982 



D. Management of Multivendor ADP Systems 

Guideline for Managing Multivendor Plug-Compatible ADP Systems 
FIPSPUB 56 15 September 1978 
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APPENDIX B 



FIPS TASK GROUPS 

Objectives and Requirements for Standards 
Data Terminals and Data Interchange System Requirements 
Character Subsets, Sign Conventions and Packing Techniques 
Subsections on Standards for Use in Requests for Proposals 
Federal Information Processing Vocabulary 
Computer Magnetic Tapes 

Magnetic Tape Labels for Information Interchange 
Guidelines for Describing Data Interchange Formats 
COBOL Standards 

Guidelines for Computer System and Component Performance 
Evaluation 

Optical Character Recognition 

Significance and Impact of ASCII as a Federal Standard 
Workload Definition/Benchmarking 

Documentation for Information Processing Systems 
Computer Systems Security 
Basic Standard Programming Language 
Data Element Dictionary 
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APPENDIX C 



FUNCTIONS OF OP-945 



1. Serves as principal advisor to OP-094 on all matters per- 
taining to information systems resources including: information 
resources management, information requirements, information and 
office systems, embedded computer resources, mission critical 
computers, data processing, records and forms management, post- 
al affairs, and computer security. 

2. Supports the senior official designated in accordance with 

the Paperwork Reduction Act of 1980 (PL96-511) and the DON Senior 

ADP Policy Official. 

3. Acts to encourage effective and efficient use of informa- 
tion systems technology in support of DON missions. 

4. Maintains awareness of external policy and regulations 
impacting Division programs, influences development and modifi- 
cation of those policies and regulations to the extent appropriate, 
and assures DON compliance. 

5. Develps DON and Navy policy, procedures, objectives, man- 
uals, handbooks, criteria, and other issuances as needed for 
implementation of the Division programs. 

6. Maintains awareness of DOD, Federal, industry, and academic 
developments and actions of potential concern to the Division 
and promulgates such information as appropriate. 

7. Coordinates action on GAO, Congressional, internal audit, 
inspector general, and other reviews, surveys, and audits in 
areas of concern to the Division. 

8. Represents the DON externally on matters concerning Divi- 
sion programs not related to specific information systems. 

9. Represents the DON externally on matters concerning spe- 
cific information systems. 

10. Validates information requirements, assuring that they 
are justified and non-duplicative , and that effective informa- 
tion systems support is provided. 

11. Develops the top level information systems architecture 
for the DON and the strategic information systems plan in sup- 
port of that architecture. 
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12. Provides leadership to teams charged to develop informa- 
tion systems architecture for designated systems. 

13. Monitors the development and implementation of informa- 
tion systems architecture and plans. 

14. Reviews plans and project approval requests for compliance 
with architecture, appropriate interface provisions and general 
soundness of approach. 

15. Assures maximum practicable standardization of informa- 
tion systems. 

16. Serves as DON Assessment Sponsor for information systems 
and otherwise review, prepares, and defends Program Objectives 
Memorandum and budget Submissions as appropriate. 

17. Serves as program coordinator for designated programs such 
as THAIS, STAIRS, Fleet Work Processing Program, SNAP, and 
AN/UYK-43/44 . 

18. Acts as designator advisor for designators and ratings 
covered by Division programs and sponsors a civilian career 
management program for related series. 

19. Sponsors development and promulgation of information sys- 
tems technical standards. 

20. Sponsors development of new information methods and tech- 
nology, including information requirements description techniques, 
and acts to obtain effective use of new developments in DON in- 
formation systems. 

21. Assures appropriate training for users of information systems. 

22. Provides for the registration and standardization of data 
elements . 

23. Assesses progress and status of Division programs at least 
annually . 

24. Advises OP-094 on CNO command related matters affecting 
NAVDAC and serves as NAVDAC program coordinator. 
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